Method and system for providing seller bank receivable discounting services

ABSTRACT

A system for conducting commercial transactions between buyers and sellers is disclosed. The system includes a transaction processing system for facilitating payment for transactions between buyers and the sellers. In addition to the buyer and the seller, the transaction processing system also interacts with issuers and acquirers. The transaction processing system monitors and manages payment information relating to transactions conducted between buyers and sellers. Using such information, the transaction processing system further offers a number of additional financing services including, for example, buyer payment assurance, buyer bank payment assurance, buyer bank payable discounting, buyer bank payable discount aggregation, seller/receivable financing and seller bank receivable discount aggregation.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claiming benefit under 35 U.S.C. 119(e) of U.S.Provisional Patent Application No. 60/581,021 filed Jun. 17, 2004entitled METHOD AND SYSTEM FOR PROVIDING ASSURANCE AND FINANCINGSERVICES which is hereby incorporated by reference, as if set forth infull in this document, for all purposes.

BACKGROUND OF THE INVENTION

The present invention generally relates to assurance and financingservices, and more specifically, to a method and system for providingassurance and financing services to buyers and sellers involved incommercial transactions.

In business-to-business transactions, buyers and sellers can establishrelationships with one another in a number of different ways. Forexample, when the transactional volume and/or amount reaches a certainlevel, a buyer and a seller typically enter into a sales agreement tominimize the risks of exposure and breach by either party. In addition,when a buyer and a seller wish to establish a long-term relationshipwith one another, they also typically enter into a sales agreement whichincludes the terms and conditions which govern the rights andobligations of the parties whenever they deal with each other, therebyavoiding the need to negotiate terms and conditions for each transactionon an ad hoc basis.

While sales agreements are routinely used by buyers and sellers toestablish contractual relationships with one another, the terms andconditions of a sales agreement typically still need to be reviewed andapplied to each transaction manually. In other words, even when a buyerand a seller have established a long-term contractual relationship viaexecution of a sales agreement, whenever a transaction is to becompleted between the parties, both parties still need to manuallyensure that the transaction is compliant with the terms and conditionsof the sales agreement. The examination of the terms and conditions ofthe sales agreement is usually done by a human being on an individualbasis for each transsection. This manual examination process is oftentedious, time-consuming and prone to errors. Therefore, it would bedesirable to have a system which is capable of storing and applying inan automated manner the terms and conditions of a sales agreementbetween a buyer and a seller for transactions conducted between theparties.

Furthermore, a buyer and a seller may have more than one sales agreementbetween the parties. In fact, as between a buyer and a seller who have along-term relationship, various types of sales agreements often existand apply to different types of transactions between the parties.Manually reviewing these various types of sales agreements to determinewhich specific sale agreement applies to a particular transaction isobviously inefficient. Therefore, it would also be desirable to have asystem which is capable of collectively storing and maintaining termsand conditions of sales agreements between a buyer and a seller.

A transaction between a buyer and a seller is typically completed in thefollowing manner. A buyer usually issues a purchase order to a sellerfor goods and/or services which the buyer wishes to purchase. Uponreceipt of the purchase order, the seller ships the goods to the buyer.The seller generally simultaneously forwards an invoice for the amountdue when the goods are shipped. It is up to the buyer to honor thatinvoice and pay within an agreed upon period of time. Payment by thebuyer is typically made via check or money transfer. Alternatively,payment can also be made via credit cards or similar creditarrangements.

A normal credit card transaction involves a number of parties, includinga buyer who possesses a credit card, a seller, an acquirer, an issuerand a credit card association such as Visa or Mastercard. The acquireris a business entity, e.g., a commercial bank, that has a businessrelationship with the seller and receives all the credit cardtransactions from that seller. The issuer is a business entity whichissues the credit card to the buyer. The credit card association such asVisa maintains a network of processing applications, e.g., VisaNet,which facilitates issuance of credit cards and processing of credit cardtransactions.

A typical credit card transaction involves the following steps. First,the seller calculates the amount of the transaction or purchase andseeks payment from the buyer. The buyer then presents the seller withhis/her credit card. The seller then runs the credit card through apoint of sale terminal. The point of sale terminal captures credit cardand sales information and sends such information together with anauthorization request to the acquirer. The acquirer, in turn, processesthe information received from the point of sale terminal and forwardsany relevant information and the authorization request to the issuer.The issuer processes the relevant information and the authorizationrequest to determine whether the transaction should be authorized. Theissuer then sends an approval or denial code back to the acquirer. Theacquirer relays the approval or denial code to the point of saleterminal for use by the seller. If the transaction is authorized, thebuyer is allowed to consummate the transaction with the seller.Typically, at a later time, the accounts maintained by the issuer andthe acquirer are settled and reconciled. The issuer transfers thetransaction amount minus a fee to the acquirer. The acquirer thendeducts a fee from the amount received from the issuer. The remainingamount is then transferred by the acquirer to the seller's account. Aseparate fee is charged by the credit card association for use of itsnetwork to facilitate the transaction.

Credit card transactions are generally well accepted. Computer systemshave been developed to process these transactions in a reliable andsecure manner. One such computer system known as VisaNet is developed byVisa to process credit card transactions. Therefore, it would bedesirable to have a system which is capable of taking advantage ofcurrently available computing resources thereby further expediting andfacilitating transactions between buyers and sellers.

SUMMARY OF THE INVENTION

A system for conducting a commercial transaction between a buyer and aseller is disclosed. The system includes a transaction processing systemfor facilitating payment for a transaction between the buyer and theseller. In addition to the buyer and the seller, the transactionprocessing system also interacts with an issuer, an acquirer and acredit card association, such as Visa (via VisaNet). The issuer issuesand manages an account for the buyer. The acquirer manages an accountfor the seller.

Before the transaction processing system is used to process transactionsbetween the buyer and the seller, certain information is obtained fromthe buyer, the seller, the issuer and the acquirer and stored on thesystem. Each buyer and seller are registered in the system. Uponregistration, the pre-negotiated terms and conditions which are to beused to govern the transactions between the buyer and the seller arecollected and stored on the system. Such terms and conditions areobtained, for example, from a sales agreement between the buyer and theseller. In addition, the system also stores pre-negotiated terms andconditions agreed to amongst the buyer, the seller, the issuer and theacquirer.

The transaction processing system handles a transaction between a buyerand a seller in the following exemplary manner. An electronic invoice isfirst posted to the system by the seller or another system. Uponaccepting the electronic invoice, the system creates one or more paymentinstructions. Each payment instruction corresponds to a paymenttransaction. Typically, one invoice represents one payment transaction,and hence, one payment instruction is created. However, it should beunderstood that multiple payment instructions may be created from asingle invoice because a single invoice may represent multiple paymenttransactions. Alternatively, the buyer can cause the system to create apayment instruction without a corresponding electronic invoice.

Each time a payment instruction is created, the system applies some orall of the previously stored pre-negotiated payment terms and conditionsbetween the buyer and the seller to the payment instruction. Forexample, if terms for a given buyer-seller contract state that paymentis due 45 days from invoice date, that information would be included inthe payment instruction when the payment instruction is created.

After a payment instruction is created, the system seeks approval fromthe buyer. The approval can be provided by the buyer through aninterface to the system. Alternatively, the approval can be supplied bya third party system on behalf of the buyer. Upon approval of a paymentinstruction by the buyer, the system schedules the payment for thespecified date in the payment instruction. On the scheduled day ofpayment, the system calculates one or more fees, such as a transactionfee, for that particular payment transaction according to a pre-definedvariable pricing matrix, which is determined based on the set ofpre-negotiated terms and conditions agreed to by the issuer, theacquirer, the seller and the buyer.

The transaction fee is an amount used by the issuer and the acquirer tocompensate each other for processing the payment transaction on behalfof the buyer and the seller. The respective portions of the transactionfee to be received by the issuer and the acquirer may vary. For example,the transaction fee may be shared by the issuer and the acquirer equallyor based on some pre-determined percentage, or alternatively, thetransaction fee may belong solely to the issuer. After the transactionfee is calculated, information relating to the transaction fee and thepayment instruction is formatted into a proper message format(s) andsubmitted for authorization, clearing and settlement. The issuer and theacquirer then communicate with one another directly or indirectly tosettle the funds. Additionally, the system provides transaction andactivity reports to all relevant parties as well as access to statusinformation for invoices and payments.

Accordingly, in an exemplary embodiment, a system for executing apayment transaction between a buyer and a seller, comprises: a firstinterface configured to allow invoices to be submitted for payment; asecond interface configured to allow the buyer to receive and approveinvoices and create and approve payment instructions; and a transactionprocessing module configured to handle buyer account(s) and selleraccount(s) respectively, the transaction processing module is furtherconfigured to store a plurality of conditions relating to the buyer, theseller, an issuer and an acquirer; and wherein the transactionprocessing module enables the issuer and the acquirer to process theinvoices in accordance with the plurality of conditions.

Accordingly, in another exemplary embodiment, a method for processing apayment transaction between a buyer and a seller, comprises: maintaininga buyer account and a seller account for the buyer and the sellerrespectively; maintaining a plurality of terms and conditions relatingto the buyer, the seller, an issuer and an acquirer; approving thepayment transaction for payment out of the buyer account; determining atransaction fee for the payment transaction based on the plurality ofterms and conditions; calculating a net amount using the transactionfee; obtaining payment authorization for the payment transaction fromthe issuer; and settling the payment transaction between the issuer andthe acquirer.

In one exemplary embodiment, the transaction processing system furtherincludes a number of additional features including, for example, buyerpayment assurance, buyer bank payment assurance, buyer bank payablediscounting, buyer bank payable discount aggregation, seller/receivablefinancing and seller bank receivable discount aggregation.

Reference to the remaining portions of the specification, including thedrawings and claims, will realize other features and advantages of thepresent invention. Further features and advantages of the presentinvention, as well as the structure and operation of various embodimentsof the present invention, are described in detail below with respect toaccompanying drawings, like reference numbers indicate identical orfunctionally similar elements.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified schematic diagram illustrating the processinteraction of an exemplary embodiment of the present invention;

FIG. 2 is a simplified schematic diagram illustrating an exemplaryembodiment of the transaction processing system in accordance with thepresent invention;

FIG. 3 is a diagram illustrating examples of the Transaction Fee Termsand Conditions; and

FIG. 4 is a flow diagram illustrating how the net amount for eachtransaction is calculated in accordance with am exemplary embodiment ofthe present invention.

DETAILED DESCRIPTION OF THE INVENTION

The present invention in the form of one or more exemplary embodimentswill now be described. Referring to FIG. 1, there is shown the processinteraction of an exemplary embodiment of the present invention.According to this exemplary embodiment, a transaction processing system10 is designed to interact with a number of different parties involvedin a transaction including, a buyer 12, a seller 14, an issuer 16, anacquirer 18 and a credit card association, such as Visa (via VisaNet).The buyer 12 can be a person or business entity which has contractedwith the seller 14 to purchase goods and/or services.

Similarly, the seller 14 can be a person or business entity which hasestablished a relationship with the buyer 12 to provide goods and/orservices to the buyer 12. Such relationship is typically established viaa written contract or agreement. For example, the buyer 12 may enterinto a contract with the seller 14 on a long-term basis to have theseller 12 be the exclusive provider of office supplies or othercommodities for the buyer 12. The relationship between the buyer 12 andthe seller 14 will be explained further below.

The issuer 16 can be a business entity which typically is a financialinstitution such as a bank. The issuer 16 issues one or more transactionaccounts to the buyer 12 and is responsible for maintaining and handlingthe transaction account activities of the buyer 12 in cooperation withthe transaction processing system 10. It should be noted that the issuer16 may issue and maintain transaction accounts for multiple buyers 12.

Similarly, the acquirer 18 can also be a business entity which typicallyis a financial institution such as a bank. The acquirer 18 is contractedwith the seller 14 to accept seller sales drafts and instructionsrelating to the transaction accounts issued by issuer 16. Furthermore,the acquirer 18 also maintains one or more transaction accounts for theseller 14 and is responsible for maintaining and handling thetransaction account activities of the supplier 14 in cooperation withthe transaction processing system 10. The acquirer 18 may also maintainsimilar accounts for multiple sellers 14.

Generally, the transaction processing system 10 stores and managestransaction accounts for buyers 12 and sellers 14 respectively. Itshould be understood that a single buyer 12 or seller 14 may havemultiple transaction accounts from which payment can be debited and/orcredited. In addition, the transaction processing system 10 stores andmaintains terms and conditions relating to those transaction accounts.These terms and conditions are usually provided to the transactionprocessing system 10 at the time of registration of the buyer 12 and/orthe seller 14. These terms and conditions include, for example,pre-negotiated payment terms and conditions between the buyer 12 and theseller 14, which are to be used to govern transactions between theparties and can be obtained from various sources, such as a salesagreement between the buyer 12 and the seller 14. As will be furtherexplained below, these terms and conditions are selectively used toprocess the transactions between the buyer 12 and the seller 14.

The transaction processing system 10 also provides the capability tostore information relating to the issuers 16 and the acquirers 18. Suchinformation can be used to determine the appropriate amount oftransaction fee to be used by the issuer 16 and the acquirer 18 tocompensate each other.

Furthermore, the transaction processing system 10 also allows the issuer16 and the acquirer 18 to create and maintain buyer and sellertransaction accounts respectively. In order for the transactionprocessing system 10 to handle a transaction for the buyer 12 and theseller 14, both the buyer 12 and the seller 14 need to be registered orotherwise have their respective transaction accounts established withthe transaction processing system 10. Additional details of thetransaction processing system 10 will be further explained below.

The transaction processing system 10 operates in the following exemplarymanner. The processing of a single invoice is illustrated below.However, it should be understood that multiple invoices can be processedby the transaction processing system 10 at the same time. As apreliminary step (not shown in FIG. 1), when the buyer 12 decides topurchase goods and/or services from the seller 14, the buyer 12typically issues a purchase order, or via some other means communicatesthe purchase order, to the seller 14. Upon receiving the purchase order,the seller 14 then ships the ordered goods or provides a service to thebuyer 12.

Referring now to FIG. 1, after receiving the purchase order, the seller14 issues an electronic invoice either directly or indirectly through acomplementary system (e.g., an e-procurement system) to the transactionprocessing system 10. In an exemplary embodiment, the transactionprocessing system 10 includes an interface which allows invoices to beposted directly by the seller 14 to the transaction processing system10.

Upon accepting the invoice, the transaction processing system 10, inturn, creates one or more payment instructions. Each payment instructioncorresponds to a payment transaction. Typically, one invoice representsone payment transaction, and hence, one payment instruction is usuallycreated for each invoice. However, it should be understood that multiplepayment instructions may be created from a single invoice because asingle invoice may represent multiple payment transactions. The paymentinstruction includes payment terms and conditions between the buyer 12and the seller 14 which are previously stored on the transactionprocessing system 10 and relevant to that particular paymenttransaction. Alternatively, the buyer 12 can cause a payment instructionto be generated by the transaction processing system 10 without anyaccompanying invoice.

After the payment instruction is created, the transaction processingsystem 10 seeks approval for that payment instruction from the buyer 12.The approval can be provided by the buyer 12 through an interface to thetransaction processing system 10. Alternatively, the approval can besupplied by a third party system on behalf of the buyer 12. Uponapproval of the payment instruction by the buyer 12, the transactionprocessing system 10 schedules the payment for the specified date in thepayment instruction.

On the scheduled day of payment, the transaction processing system 10initiates processing of a payment from a transaction account belongingto the buyer 12 pursuant to the payment instruction.

Upon initiation of processing of the approved payment instruction, thetransaction processing system 10 first determines one or more fees, suchas a transaction fee, for that particular payment transaction. Thetransaction fee is an amount used by the issuer 16 and the acquirer 18to compensate each other for processing the payment transaction. Theamount of the transaction fee is determined based on terms andconditions previously agreed to amongst the buyer 12, the seller 14, theissuer 16 and the acquirer 18. Furthermore, the respective portions ofthe transaction fee to be received by the issuer 16 and the acquirer 18may vary depending on the arrangement agreed to between the issuer 16and the acquirer 18. Determination of the transaction fee and theseterms and conditions will be further explained below.

Using the transaction fee and other specified fees, if any, thetransaction processing system 10 then calculates the net amount to bereceived by the seller 14 for the payment transaction being processed.Calculation of the net amount will be further described below.

The transaction processing system 10 also prepares an authorizationrequest which is forwarded to the issuer 14 via a data transport andprocessing network 20, such as VisaNet.

Once the authorization request is approved by the issuer 14, anauthorization response is sent by the issuer 14 to the transactionprocessing system 10. Upon receipt of the authorization response, thetransaction processing system 10 forwards a settlement file to theacquirer 18 via the data transport and processing network 20. Thesettlement file includes, among other information, the invoice amount(gross amount), the transaction fee and the net amount (the gross amountminus the transaction fee and other specified fees, if any).

After the settlement file is received by the acquirer 18, the acquirer18 issues a request for the transfer of funds. The settlement of fundsis then sent from the issuer 16 to the acquirer 18. This settlement offunds between the issuer 16 and the acquirer 18 typically occurs withinthe data transport and processing network 20. The settlement of fundsalso occurs between the buyer 12 and the issuer 16 and between theseller 14 and the acquirer 18. More specifically, the buyer 12 forwardsor credits the payment amount (or consolidated payments) to the issuer16 to cover for payment and processing of the payment transaction by theissuer 16 and the acquirer 18 credits the net amount to the seller 14.The settlement of funds between the buyer 12 and the issuer 16 andbetween the seller 14 and the acquirer 18 occurs outside of thetransaction processing system 10.

As shown in FIG. 1, in an exemplary embodiment, the transactionprocessing system 10 interacts with the data transport and processingnetwork 20 in order to carry out certain payment processing,authorization and/or settlement functions. The data transport andprocessing network 20 globally connects the processing systems for allparticipating issuers 16 and acquirers 18. As previously mentioned, anexample of the data transport and processing network 20 is VisaNet.

Referring to FIG. 2, there is shown an exemplary embodiment of thetransaction processing system 10. According to this exemplaryembodiment, the transaction processing system 10 includes fivecomponents, namely, an invoice pre-processor 22, a payment manager 24,an issuer pricing engine 26, an authorization and settlement interface28 and a payment results manager 30. Preferably, these five componentsare implemented in a modular manner; however, it should be understoodthat they can be implemented in an integral manner as well.

It should also be understood that these five components are provided forillustrative purposes only. The transaction processing system 10 mayinclude any number of components which collectively provide thefunctionality described herein.

The invoice pre-processor 22 manages input of seller invoices andconsolidates these invoices into a standard file format. The invoicepre-processor 22 is capable of accepting seller invoices in anelectronic format. Alternatively, the invoice pre-processor 22 mayreceive invoice data which is manually inputted.

In addition, it should be understood that the term “invoice” as usedherein includes a typical invoice and any payment request pursuant towhich an amount is to be paid from the buyer 12 to the seller 14. Aninvoice does not necessarily need to originate from the seller 14 butmay be originated from a third party system which issues the invoice onbehalf of the seller 14. The buyer 12 cannot create an invoice, but cancause a payment instruction to be created without having received aninvoice.

In any event, the invoice pre-processor 22 generates a standardizedinvoice file which is then forwarded to the payment manager 24. In anexemplary implementation, the invoice pre-processor 22 combines allseller invoices into one standard file to be delivered as input into thepayment manager 24.

The payment manager 24 receives the standardized invoice file from theinvoice pre-processor 22 and processes the standardized seller invoices.For each invoice, the payment manager 24 creates a corresponding paymentinstruction. The payment instruction includes certain pre-negotiatedpayment terms and conditions, if any, between the buyer 12 and theseller 14 which are relevant to the corresponding payment transaction.Alternatively, the buyer 12 can cause a payment instruction to begenerated without any accompanying invoice. For example, thepre-negotiated payment terms and conditions may include payment timinginformation such as 2/10/net 30, etc. Other information can also beincluded to indicate that payments over a certain amount must be paidfaster, or certain types of goods can be paid over a longer period oftime, etc. In other words, this enables the buyer 12 to referenceimportant contract terms that do not relate directly to calculating thetransaction fee. If no specific set of terms or conditions exists forthat particular invoice or payment transaction, then a default set ofterms and conditions may be used. It should be noted that the paymentmanager 24 may contain default sets of terms and conditions for variousdifferent buyers 12, sellers 14, issuers 16 and acquirers 18.

After the payment instruction is created, the payment manager 24 seeksapproval for that payment instruction from the buyer 12. The approvalcan be provided by the buyer 12 via an interface to the payment manager24, or alternatively, the approval can be supplied by a third partysystem on behalf of the buyer 12. In any event, upon approval of thepayment instruction by the buyer 12, the payment manager 24 schedulesthe payment for the specified date in the payment instruction. On thescheduled day of payment, the payment manager 24 invokes the issuerpricing engine 26 to process the payment transaction, as will bedescribed further below.

The payment manager 24 keeps track of the status of each invoice orpayment transaction. Each invoice or payment transaction may assume oneof a number of status. A “scheduled” invoice is an invoice which isscheduled for payment on a particular due date. A “pending” invoice isan invoice for which an authorization request has already been issued. A“declined” invoice is an invoice which has been refused by the issuer16. An “authorized” invoice is an invoice which has been approved by theissuer 16. Finally, a “settled” invoice is an invoice for whichsettlement fund has already taken place. The payment manager 24cooperates with the payment results processor 30 to update the status ofeach pending invoice or payment transaction.

The payment manager 24 further provides various functions and servicesto the buyer 12, the seller 14, the issuer 16 and the acquirer 18.

With respect to the buyer 12, the payment manager 24 allows the buyer 12to perform a number of tasks, including, for example, (1) administeringusers belonging to the buyer 12, such as controlling user access levelsand roles with identity authentication; (2) viewing and printing alisting of open invoices; (3) viewing payment terms and conditions forsellers presenting the invoices; (4) approving or rejecting invoices;(5) selecting invoices to pay from list of open invoices; (6) viewingpayment status of invoices; (6) creating a payment for a seller if thereis no associated invoice; (8) entering or selecting payment variables,such as amount, disbursement account and date, including scheduling inadvance for deferred settlement; (9) defining and enforcing paymentapproval process and authorization levels; (10) placing payments on holdor canceling payments; (11) viewing historical invoice or paymenttransactions; and (12) downloading invoice or payment data.

With respect to the seller 14, the payment manager 24 allows the seller14 to create invoices and view the status of relevant invoices andpayments.

With respect to the acquirer 18, the payment manager 24 allows theacquirer 18 to create accounts for sellers 14 and their respectiveusers.

With respect to the issuer 16, the payment manager 24 permits the issuer16 to perform the following exemplary functions, including, for example,(1) entering payment account information for each buyer 12; (2)providing customer service to the buyer 12; and (3) creating accountsfor additional buyers 12 and their respective users.

As mentioned above, on the scheduled day of payment, the payment manager24 invokes the issuer pricing engine 26 to process the paymenttransactions. More specifically, the issuer pricing engine 26 is invokedto determine one or more fees, such as a transaction fee, associatedwith each payment transaction. These fees may be pre-negotiated amongstand/or between the various parties including the issuer 16, the acquirer18, the buyer 12 and the seller 14. For example, the transaction fee isbased on several parameters defined among the issuer 16, the acquirer18, the buyer 12 and the seller 14. These parameters are collectivelyknown as the “Transaction Fee Terms and Conditions.” The transaction feeis used by the acquirer 18 and the issuer 16 to compensate each otherfor each payment transaction. The respective portions of the transactionfee to be received by the issuer 16 and the acquirer 18 may varydepending on the arrangement agreed to between the issuer 16 and theacquirer 18. For example, the issuer 16 and the acquirer 18 may agreewith each other to split the transaction fee based on a pre-negotiatedpercentage, such as 50-50; alternatively, the issuer 16 may be entitledto receive the entire transaction fee.

The Transaction Fee Terms and Conditions are negotiated between severalparties, including, for example, (1) the buyer 12 and the seller 14; (2)the issuer 16 and the buyer 12; (3) the acquirer 18 and the seller 14;and (4) the issuer 16 and the acquirer 18. The issuer 16 is preferablyresponsible for defining, entering and maintaining the Transaction FeeTerms and Conditions using the payment manager 24. The Transaction FeeTerms and Conditions are stored in the issuer pricing engine 26 oranother database and are accessible to the relevant parties.

FIG. 3 is a diagram illustrating examples of the Transaction Fee Termsand Conditions. As shown in FIG. 3, for example, Transaction Fee Term #3applies to every payment transaction for Issuer #9012. For Issuer #1234,Transaction Fee Term #1 only applies if a payment transaction is madebetween Buyer #95 and Seller #22 using account #121212. For Issuer#5678, since no account is specified, Transaction Fee Term #2 applies toevery payment transaction between Buyer #18 and Seller #22. Otherexamples of the Transaction Fee and Terms and Conditions include a setof five transaction size ranges that apply to a hierarchy ofrelationships. The set of transaction size ranges may be paymentsbetween $0-$500, $501-$1000, $1001-$5000, etc. These ranges can beestablished by the parties involved. For example, an individual matrixcan be established for (1) each buyer and seller relationship, (2) forall sellers to a certain buyer, (3) for all sellers with a relationshipto a certain acquirer, etc. Other Transaction Fee and Terms andConditions may include additional fees for new value added services suchas guaranteed payment.

The net amount for each payment transaction is then calculated bysubtracting the transaction fee from a gross amount. The gross amountrepresents the payment amount which is to be paid by the buyer 12 forthe payment transaction being processed. Optionally, additional fees maybe deducted from the net amount. For example, the acquirer 18 mayrequire the seller 14 to pay other fees in order for the acquirer 18 tohandle certain payment transactions on behalf of the seller 14.

FIG. 4 is a flow diagram illustrating how the issuer pricing engine 26calculates the net amount for each payment transaction. At 40, theissuer pricing engine 26 receives the payment instruction correspondingto the payment transaction to be processed from the payment manager 24.At 42, the issuer pricing engine 26 attempts to retrieve a specific setof terms and conditions associated with that particular paymenttransaction for use in calculating the transaction fee. At 44, if aspecific set of terms and conditions does not exist, a default set ofterms and conditions may be retrieved at 46. In any event, the set ofterms and conditions include information, such as pricing parameters,which is used to calculate the transaction fee.

At 48, for example, the transaction size ranges and their associatedpricing factors are obtained from within the retrieved set of terms andconditions. Each range may have different pricing factors. For example,the pricing factor for the range of $0-$500 may be a basis rate which isbased purely on percent calculation, such as 1.5% of the gross amount;the pricing factor for the range of $501 to $632 may be 1% of the grossamount plus a flat fee of $5; the pricing factor for the range of $633to $999 may be purely a flat fee, etc. At 50, the transaction fee iscalculated by applying the appropriate pricing factor against the grossamount. As described above, the pricing factor may include a basis rateor percentage only, flat fee only or combination of the two withspecific and defined values. It should be understood that otherformulations or criteria may be used as the appropriate pricing factor.

At 52, the issuer pricing engine 26 determines whether the transactionfee is less than a minimum fee. The minimum fee is part of thenegotiated fees in the variable pricing negotiation between issuers,acquirers, etc. At 54, if it is determined that the transaction fee isless than the minimum fee, then the minimum fee is used as thetransaction fee.

At 56, the issuer pricing engine 26 further determines whether thetransaction fee exceeds a maximum fee. The maximum fee is also part ofthe negotiated fees in the variable pricing negotiation between issuers,acquirers, etc. If the transaction fee exceeds the maximum fee, then, at58, the maximum fee is used as the transaction fee. At 60, the netamount is calculated by subtracting the transaction fee from the grossamount. For each payment transaction, the gross amount is the paymentamount to be paid by the buyer 12, the transaction fee is the amountused by the acquirer 18 and the issuer 16 to compensate each other. Thenet amount is the amount to be received by the seller 14. Optionally,other fees may be deducted from the net amount. For example, theacquirer 18 may require the seller 14 to pay additional fees forprocessing of certain specified payment transactions.

Once the relevant amounts, such as the transaction fee and the netamount, are calculated, they are consolidated with other informationinto a calculated payment file for delivery to the authorization andsettlement interface 28. The calculated payment file is stored on anarchive database or other storage medium for archival and reportingpurposes.

The authorization and settlement interface 28 is responsible fortransmitting and receiving payment transaction authorization and/orsettlement information to and from the data transport and processingnetwork 20. For each payment transaction, the data transport andprocessing network 20 determines whether such transaction is authorized(by the issuer 16). Authorization and/or settlement results are thenprovided to the authorization and settlement interface 28.

The payment results manager 30 then receives the authorization and/orsettlement results from the authorization and settlement interface 28and further processes the results. The processed results are then passedback to the payment manager 24. The payment manager 24 then updates thestatus of the invoices or payment transactions and allows users to seewhether payments for invoices have been settled or have been declined.

In an exemplary embodiment, the transaction processing system 10 isimplemented on a server which is accessible via a computer network, suchas the Internet. Based on the disclosure provided herein, a person ofordinary skill in the art will know of ways and methods to implement thetransaction processing system 10 on a server or other configuration.

Furthermore, in order to facilitate access by various users, thetransaction processing system 10 also includes a number of userinterfaces. The user interfaces allow different users to view and/ormodify different information or data residing on the transactionprocessing system 10 depending on the access authority of such users.For example, an issuer 16 via a user interface may be able to view andmodify certain Transaction Fee Terms and Conditions relating to itsbuyers 12. A buyer 12 via another user interface may be able to viewinvoices issued by its sellers 14. A person of ordinary skill in the artwill know of other ways and methods to implement user interfaces via acomputer network which allow information and data to be accessed.

In one exemplary embodiment, the transaction processing system 10further includes a number of additional features including, for example,buyer payment assurance, buyer bank payment assurance, buyer bankpayable discounting, buyer bank payable discount aggregation,seller/receivable financing and seller bank receivable discountaggregation, each of which will be further described below. Inconnection with some of these additional features, the transactionprocessing system 10 also allows interactions and participation by otherentities including, for example, a buyer bank and a seller bank.

In one exemplary aspect, the transaction processing system 10 providesbuyer payment assurance in that a buyer 12 has the ability to provideunconditional, irrevocable assurance (guarantee) that a payment will bemade on a specified date with certainty. As described above, thetransaction processing system 10 provides the opportunity to a buyer 12to approve a payment instruction. During this approval process, thebuyer 12 has the option to specify that s/he desires to assure payment.Terms and conditions relating to payment assurance are pre-negotiatedand stored in the transaction processing system 10. For example, a buyer12 may agree to assure payment using a funding source, such as, achecking account maintained at a buyer bank. In one situation, the buyerbank and the issuer 16 may be the same entity maintaining both achecking account and a credit card account for the buyer 12. Informationrelating to the funding source can be provided and maintained in thetransaction processing system 10.

Optionally, the buyer 12 may also specify a date in connection with thepayment assurance indicating that payment will be made on or before thespecified date. Upon providing a specified date, the transactionprocessing system 10 informs the buyer 12 of settlement timeframes. Forexample, the buyer 12 can be informed that payments that are settled inU.S. dollars will post to a seller bank clearing account within one (1)business day of the payment due date and non-U.S. dollar transactionswill post to a seller bank clearing account within two (2) business daysof the payment due date.

Upon the buyer 12 indicating that a transaction is to be buyer-assured,the transaction processing system 10 “locks down” that particulartransaction and its corresponding payment instruction, i.e., informationrelating to the transaction and the corresponding payment instruction isprotected against any subsequent modifications. In addition, optionalnotification can be provided by the transaction processing system 10 tothe buyer 12, the seller 14, the buyer bank and the seller bankregarding the buyer-assured status of the transaction. Should it besubsequently decided that the transaction is to be reversed, thereversal process is performed outside of the transaction processingsystem 10.

The transaction processing system 10 further allows transactions withbuyer-assured status to be identified. Information relating to suchtransactions can then be provided to the seller 14 and/or the sellerbank for reporting purposes. Such information can then be used by theseller bank to provide financing services. For example, using theinformation, the seller bank is able to flag transactions that it hasprovided factoring for. This enables the seller bank to recognize whichtransactions are financed so that credit for these transactions will notbe passed onto the seller. Use of this information will be furtherdescribed below.

In one exemplary aspect, the transaction processing system 10 enables abuyer 12 to request and/or obtain buyer bank assurance from a buyerbank. Buyer bank assurance means that the buyer bank has agreed toguarantee payment for the transaction. During the payment instructionapproval process, the buyer 12 is able to issue a request for buyer bankassurance. Terms and conditions relating to the buyer bank assurance arepre-negotiated between the buyer 12 and the buyer bank. In oneembodiment, such terms and conditions are stored in and used by thetransaction processing system 10 to process the request. Alternatively,the request is forwarded by the transaction processing system 10 to thebuyer bank for processing. The decision made by the buyer bank is thenrelayed to the transaction processing system 10.

In the case where the request is approved, the transaction and itscorresponding payment instruction are locked down against subsequentmodification and assigned a bank-assured status. Optional notificationmay also be provided to the buyer 12, the seller 14, the buyer bank andthe seller bank.

In the case where the request is rejected, the transaction and itscorresponding payment instruction are assigned a bank-assurance-rejectedstatus and the transaction is put on hold. Optional notification mayalso be provided to the buyer 12, the seller 14, the buyer bank and theseller bank.

Similarly, information relating to transactions that have a bank-assuredstatus and for which payments are payable to the seller 14 can beprovided by the transaction processing system 10 to the seller bank.Such information can then be used by the seller bank to providefinancing services as will be further described below. This enables theseller bank to recognize which transactions are financed and guaranteedby the buyer bank so that credit for these transactions will not bepassed to the seller.

In another exemplary aspect, the transaction processing system 10provides the ability to allow a buyer bank to offer and handle advancepayment to a seller 14 at a discount; this is alternatively called“buyer bank payable discounting” (“BBPD”). This capability is designedto allow the buyer bank to offer and provide payable discounting to theseller for those future payments that the buyer bank has provided buyerbank payment assurance for. In other words, since the buyer bank hasalready guaranteed payment for certain payments payable to the seller 14as described above, the buyer bank may wish to make such payments to theseller 14 at a discount in advance of the payment due dates. This allowsthe seller 14 to receive any owed account receivables at an earlier timeprior to their due dates.

To provide the foregoing functionality, the transaction processingsystem 10 provides a graphical user interface (GUI) to allow the seller14 to display and review all its transactions that qualify for BBPD fromthe buyer bank. Qualified transactions include, for example,transactions have been granted a bank-assured status by the buyer bank.Optionally, when the buyer bank determines the bank-assured status of atransaction, the buyer bank may also indicate whether the transactionqualifies for BBPD. In some instances, the buyer bank may disqualify atransaction for BBPD even though the bank-assured status is given. Usingthe GUI, the seller 14 can then select one or more qualifiedtransactions that it would like to request for BBPD from the buyer bank.Requests pertaining to selected transactions are then forwarded by thetransaction processing system 10 to the buyer bank. A status of the“BBPD Requested” may be assigned to each selected transaction.Alternatively, the transaction processing system 10 allows the buyerbank to identify transactions that qualify for BBPD and forwardinformation relating to any identified transactions to the seller 14 forconsideration. Similarly, the seller 14 can then use the transactionprocessing system 10 to request BBPD for selected transactions.

In addition to the requests, the transaction processing system 10 mayalso forward the selected transactions to the buyer bank. Using a GUI,the buyer bank may interact with the transaction processing system 10 toreview and approve or reject the requests. In one implementation, theBBPD approval is based on at least two (2) levels according to the valueof payment associated with the transaction.

After approving a transaction, the buyer bank then uses the GUI toprovide additional information, such as, BBPD or lending terms to thetransaction processing system 10. These terms include, for example,lender's name, discount rate, start date, end date, total duration,total discount amount, handling fee, net process amount (i.e., originalpayment amount minus discount rate minus handling fee).

After the transaction has been approved by the buyer bank, thetransaction processing system 10 notifies the seller 14 of the approval.A status of “BBPD Approved” may then be assigned to the approvedtransaction. The seller 14 can then use the transaction processingsystem 10 to review the approved transaction and the associated BBPDterms. The seller 14 can then either accept or decline the approvedtransaction. If the approved transaction is accepted by the seller 14,the transaction processing system 10 displays a formal agreement forfinal approval. The formal agreement includes various types ofinformation including, for example, the BBPD terms for the approvedtransaction and any other appropriate legal verbiage. In oneimplementation, some or all of the information contained in the formalagreement is specific to the buyer bank. The transaction processingsystem 10 provides the ability for the buyer bank to provide and amendits information in the formal agreement.

Once the formal agreement is accepted by the seller 14, the transactionprocessing system 10 notifies the buyer bank and updates all recordsrelating to the approved transaction accordingly. For example, a statusof “BBPD Buyer Bank Financed/Seller Accepted” is assigned to theapproved transaction. The approved transaction and associatedinformation is then forwarded to the buyer bank for additionalprocessing.

In the event that the buyer bank rejects a selected transaction forwhich BBPD is requested, a status of “BBPD Rejected” may be assigned tothe rejected transaction.

As described above, a transaction may be assigned one of a number ofstatuses. The transaction processing system 10 provides the ability toallow different parties, e.g., the seller 14 and the buyer bank, to sorttransactions based on status.

While the foregoing describes primarily interactions between a seller 14and a buyer bank with respect to BBPD, it should be understood that thetransaction processing system 10 is able to handle a number of sellers14 and buyer banks working with each other at the same time. In oneinstance, a seller 14 may be working with a number of buyer banks; inanother instance, a buyer bank may be working with a number of sellers14.

In yet another exemplary aspect, the transaction processing system 10provides the ability to monitor future payables to individual sellers.This enables buyer banks to develop tranches to be used for lines ofcredit to sellers 14. A tranche is an aggregation of payables whichrepresents a line of credit that can be offered to a seller 14.Typically, the payables in a tranche are several related securities butneed not be so. Tranches usually have different, risk, reward and/ormaturity characteristics. This is alternatively called “buyer bankpayable discounting aggregation” (“BBPDA”).

As described above, the transaction processing system 10 keeps track ofinformation relating to payables for transactions based on the buyer 12,the seller 14 and the buyer bank. In addition, payables for transactionscan be identified as “secured” or “unsecured” by the transactionprocessing system 10. A payable or payment is secured if it isbank-assured (e.g., a buyer bank has guaranteed payment) or otherwisesecured by other assets.

The transaction processing system 10 allows the buyer bank to developtranches using the available payable information. For example, tranchescan be identified based on a mix of secured/unsecured payables, such as,a 30-day tranche having 60% secured payables and 40% unsecured payables.

Criteria for a tranche can be specified to the transaction processingsystem 10 by the buyer bank via, for example, a graphical userinterface. For example, the buyer bank can specify that a tranche needsto have $1 million due between fifteen (15) and thirty (30) days with atleast 70% of payables secured. Using the specified criteria, thetransaction processing system 10 monitors the payable information andbuilds the desired tranche. When sufficient payables are identified thatsatisfy the foregoing criteria, the transaction processing system 10builds the corresponding tranche. All identified payables are thenassociated with the corresponding tranche. It should be noted that oncea payable is used to build a first tranche, it cannot be used in anothertranche as long as that payable is associated with that first tranche.However, a payable can be made to associate with another tranche. Forexample, if a payable no longer qualifies for association with the firsttranche, it can then be associated with another tranche.

Once a tranche is built, the buyer bank is notified by the transactionprocessing system 10 that the desired tranche is available. The buyerbank can then offer the tranche to the seller 14 as a line of credit.The line of credit may be subject to certain terms and conditions set bythe buyer bank. For example, the buyer bank may discount one or morefuture payables in the tranche. The transaction processing system 10 canrelay the tranche offer and the associated terms and conditions to theseller 14.

In one implementation, a tranche corresponds to only one buyer bank andpayables associated therewith belong to only one seller 14. In otherwords, the transaction processing system 10 allows a buyer bank to builda tranche using its payables that belong to a particular seller 14.

In addition, the transaction processing system 10 allows a seller 14 torequest BBPDA. The request may include information, such as,identification of one or more buyer banks and terms and conditionsdesired by the seller 14. Once the request is received and if no buyerbank is specified, the transaction processing system 10 identifiespayables that are owed to the seller 14 and informs one or more buyerbanks that have outstanding payables owed to the seller 14 of theissuance of the BBPDA request by the seller 14. The one or more buyerbanks may then use the transaction processing system 10 to create anappropriate tranche and respond to the seller 14. If a particular buyerbank is specified, then the transaction processing system 10 accordinglycontacts the specified buyer bank.

Once a tranche is made available to the seller 14, the transactionprocessing system 10 monitors and manages the activities relating to thetranche, for example, the seller 14 drawing against the tranche. Thetransaction processing system 10 also provides the ability for theseller 14 to push a credit back to the buyer bank for any funds due thebuyer bank (e.g., balance of line of credit and/or additional interest).

In addition, the transaction processing system 10 monitors payables inthe tranche that have been paid by a buyer 12. The transactionprocessing system 10 notifies the buyer bank when a payment for payableassociated with the tranche is made by the buyer 12. When the buyer bankreceives the payment, the buyer bank uses the transaction processingsystem 10 to send a message to the seller 14 letting the seller 14 knowhow to close the corresponding transaction on its system.

In one exemplary aspect, the transaction processing system 10 providesthe ability for a seller bank to provide financing to a seller 14 for agiven payment. This is similar to BBPD described above. The transactionprocessing system 10 allows the seller bank to monitor receivables thatthe seller bank is going to receive on behalf of the seller 14. As aresult, the seller bank is able to use the transaction processing system10 to create an advance loan against a future payment/receivable.

In one scenario, the transaction processing system 10 allows the sellerbank to proactively search for transactions that the seller may wish toreceive financing. Optionally, to facilitate the search and identifyqualified transactions, the transaction processing system 10 notifiesthe seller bank when a transaction is assigned a buyer-assured and/orbank-assured status. In addition, the transaction processing system 10may provide functionality to allow the seller bank to search forqualified transactions using different criteria. Such criteria include,for example, specific sellers, sellers that are willing to considerfinancing, and transaction status, payment total, payment date, etc.Alternatively, the transaction processing system 10 allows the seller 14to identify and select transactions that it wishes to obtain financing.Information relating to the selected transactions is then forwarded tothe seller bank. The seller bank then determines which of thetransactions selected by the seller 14 are to be offered financing.

Upon the seller bank identifying the qualified transactions, thetransaction processing system 10 assigns a status of “Seller FinancingOffered” to these transactions. Optionally, the transaction processingsystem 10 allows the seller bank to provide financing terms andconditions associated with these transactions. Information relating tothese transactions and corresponding financing terms and conditions arethen forwarded to the seller 14 for review and selection.

The seller 14 can then accept or reject each of the offeredtransactions. The transaction processing system 10 accordingly assignsthe appropriate status to each transaction, such as, “Seller FinancingAccepted” or “Seller Financing Rejected”.

If a financing offer is accepted, the transaction processing system 10then collects the relevant information and forwards such information tothe seller bank for further processing. Optionally, when a financingoffer is accepted, the transaction processing system 10 may display aformal agreement for approval by the seller 14. The formal agreementincludes various types of information, such as, terms and conditions andother legal verbiage associated with the financing offer.

In one exemplary embodiment, the transaction processing system 10provides the ability to monitor future receivables to individualsellers. This is similar to BBPDA described above. This enables sellerbanks to develop tranches to be used for lines of credit to sellers 14.A tranche is an aggregation of receivables which represents a line ofcredit that can be offered to a seller 14. Typically, the receivables ina tranche are several related securities but need not be so. Tranchesusually have different, risk, reward and/or maturity characteristics.This is alternatively called “seller bank receivable discountingaggregation” (“SBRDA”).

As described above, the transaction processing system 10 keeps track ofinformation relating to receivables for transactions based on the buyer12, the seller 14 and the seller bank. In addition, receivables fortransactions can be identified as “secured” or “unsecured” by thetransaction processing system 10. A receivable is secured if it isbank-assured (e.g., a buyer bank has guaranteed payment) or otherwisesecured by other assets.

The transaction processing system 10 allows the seller bank to developtranches using the available receivable information. For example,tranches can be identified based on a mix of secured/unsecuredreceivables, such as, a 30-day tranche having 60% secured receivablesand 40% unsecured receivables.

Criteria for a tranche can be specified to the transaction processingsystem 10 by the seller bank. For example, the seller bank can specifythat a tranche needs to have $1 million due between fifteen (15) andthirty (30) days with at least 70% of receivables secured. Using thespecified criteria, the transaction processing system 10 monitors thereceivable information and builds the desired tranche. When sufficientreceivables are identified that satisfy the foregoing criteria, thetransaction processing system 10 builds the corresponding tranche. Allidentified receivables are then associated with the correspondingtranche. It should be noted that once a receivable is used to build afirst tranche, it cannot be used in another tranche as long as thatreceivable is associated with that first tranche. However, a receivablecan be made to associate with another tranche. For example, if areceivable no longer qualifies for association with the first tranche,it can then be associated with another tranche.

Once a tranche is built, the seller bank is notified by the transactionprocessing system 10 that the desired tranche is available. The sellerbank can then offer the tranche to the seller 14 as a line of credit.The line of credit may be subject to certain terms and conditions set bythe seller bank. For example, the seller bank may discount one or morefuture receivables in the tranche. The transaction processing system 10can relay the tranche offer and the associated terms and conditions tothe seller 14.

In one implementation, a tranche corresponds to only one seller bank andreceivables associated therewith belong to only one seller 14. In otherwords, the transaction processing system 10 allows a seller bank tobuild a tranche using its receivables that belong to a particular seller14.

In addition, the transaction processing system 10 allows a seller 14 torequest SBRDA. The request may include information, such as,identification of one or more seller banks and terms and conditionsdesired by the seller 14. Once the request is received and if no buyerbank is specified, the transaction processing system 10 identifiesreceivables that are owed to the seller 14 and informs one or moreseller banks that have outstanding receivables owed to the seller 14 ofthe issuance of the SBRDA request by the seller 14. The one or moreseller banks may then use the transaction processing system 10 to createan appropriate tranche and respond to the seller 14. If a particularseller bank is specified, then the transaction processing system 10accordingly contacts the specified seller bank.

Once a tranche is made available to the seller 14, the transactionprocessing system 10 monitors and manages the activities relating to thetranche, for example, the seller 14 drawing against the tranche. Thetransaction processing system 10 also provides the ability for theseller 14 to push a credit back to the seller bank for any funds due theseller bank (e.g., balance of line of credit and/or additionalinterest).

In addition, the transaction processing system 10 monitors receivablesin the tranche that have been received from a buyer 12. The transactionprocessing system 10 notifies the seller bank when a payment forreceivable associated with the tranche is made by the buyer 12. When theseller bank receives the payment, the seller bank uses the transactionprocessing system 10 to send a message to the seller 14 letting theseller 14 know how to close the corresponding transaction on its system.

The transaction processing system 10 further includes reportingmechanisms which generate reports for various parties for a number ofpurposes. Based on the disclosure and teachings provided herein, aperson of ordinary skill in the art will appreciate how to generatevarious types of reports using the present invention.

It should be understood that the present invention can be implemented inthe form of control logic, in a modular or integrated manner, usingsoftware, hardware or a combination of both. Based on the disclosure andteachings provided herein, a person of ordinary skill in the art willappreciate other ways and/or methods to implement the present invention.

It is understood that the examples and embodiments described herein arefor illustrative purposes only and that various modifications or changesin light thereof will be suggested to persons skilled in the art and areto be included within the spirit and purview of this application andscope of the appended claims. All publications, patents, and patentapplications cited herein are hereby incorporated by reference for allpurposes in their entirety.

1. A system for providing receivable discounting services, comprising: control logic configured to monitor a plurality of transactions between a buyer and a seller, wherein for each transaction, a payment is owed by the buyer to the seller; and control logic configured to allow a seller bank to offer seller bank receivable discounting (SBRD) to the seller using information collected from monitoring the plurality of transactions; wherein the seller bank handles processing of receivables for the plurality of transactions on behalf of the seller.
 2. The system of claim 1 wherein the control logic configured to allow the seller bank to offer seller bank receivable discounting (SBRD) to the seller further comprises: control logic configured to display to the seller transactions that qualify for SBRD from the seller bank and allow the seller to request SBRD for one or more transactions selected from the qualified transactions; and control logic configured to allow the seller bank to approve the selected one or more transactions for SBRD.
 3. The system of claim 2 wherein the control logic configured to allow the seller bank to offer seller bank receivable discounting (SBRD) to the seller further comprises: control logic configured to allow the seller bank to identify the transactions that qualify for SBRD before they are displayed to the seller.
 4. The system of claim 2 wherein the control logic configured to display includes a graphical user interface configured to display the transactions that qualify for SBRD to the seller.
 5. The system of claim 2 wherein the control logic configured to allow the seller bank to approve the selected one or more transactions for SBRD includes a graphical user interface configured to allow the seller bank to review and approve the selected one or more transactions for SBRD.
 6. The system of claim 2 further comprising: control logic configured to allow the buyer to request assurance from a buyer bank for one or more transactions; and control logic configured to determine whether to provide assurance to the one or more transactions requested by the buyer and assign a bank-assured status to each transaction for which assurance is to be provided; wherein the transactions that qualify for SBRD include transactions having the bank-assured status and/or transactions that have been approved by the seller bank for SBRD.
 7. The system of claim 2 wherein the control logic configured to allow the seller bank to offer seller bank receivable discounting (SBRD) to the seller further comprises: control logic configured to maintain general terms and conditions provided by the seller bank for SBRD, wherein the general terms and conditions can be modified by the seller bank; control logic configured to allow the seller bank to specify terms and conditions corresponding to each of the approved transactions for SBRD; and control logic configured to present to the seller for acceptance the approved transactions, the general terms and conditions, and the specified terms and conditions corresponding to each of the approved transactions for SBRD.
 8. The system of claim 1 further comprising: control logic configured to inform the seller of a seller bank SBRD offer; and control logic configured to allow the seller to accept or reject the seller bank SBRD offer.
 9. The system of claim 8 further comprising: control logic configured to present a formal agreement to the seller upon the seller accepting the seller bank SBRD offer.
 10. A system for providing receivable discounting services, comprising: a plurality of buyers; a plurality of sellers; a plurality of buyer banks handling payable processing for the plurality of buyers; and a transaction processing system configured to: monitor a plurality of transactions conducted between the plurality of buyers and the plurality of sellers, wherein for each transaction, a payment is owed by a buyer to a seller; and allow the plurality of seller banks to offer seller bank receivable discounting (SBRD) to one or more of the plurality of sellers using information collected from monitoring the plurality of transactions.
 11. The system of claim 10 wherein the transaction processing system is further configured to: display to one or more of the plurality of sellers respectively transactions that qualify for SBRD from one or more of the plurality of seller banks; allow the one or more of the plurality of sellers to request SBRD for one or more transactions selected from the qualified transactions, wherein a seller is only able to request SBRD from a seller bank if that seller bank has one or more receivables from corresponding transactions belonging to the seller; and allow the one or more of the plurality of seller banks to approve the selected one or more transactions for SBRD.
 12. The system of claim 11 wherein the transaction processing system is further configured to: allow the plurality of seller banks to identify the transactions that qualify for SBRD before they are displayed to the one or more of the plurality of sellers.
 13. The system of claim 11 wherein the transaction processing system is further configured to: inform a seller bank of a transaction that potentially qualifies for SBRD when that transaction is assigned a bank-assured status, wherein the seller bank is in charge of handling a receivable pertaining to that transaction.
 14. The system of claim 11 wherein the transactions that qualify for SBRD include transactions having a bank-assured status and/or transactions that have been approved respectively by the one or more of the plurality of seller banks for SBRD.
 15. The system of claim 11 wherein the transaction processing system is further configured to: maintain general terms and conditions provided respectively by one or more of the plurality of seller banks for SBRD, wherein the general terms and conditions can be modified by the one or more of the plurality of seller banks; allow one or more of the plurality of seller banks to specify respectively terms and conditions corresponding to each of the approved transactions for SBRD; and present to one or more of the plurality of sellers for acceptance respectively the approved transactions, the general terms and conditions, and the specified terms and conditions corresponding to each of the approved transactions for SBRD.
 16. The system of claim 10 wherein the transaction processing system further comprises: control logic configured to inform one or more of the plurality of sellers respectively of one or more seller bank SBRD offers; and control logic configured to allow the one or more of the plurality of sellers to respectively accept or reject the one or more seller bank SBRD offers.
 17. The system of claim 16 wherein the transaction processing system further comprises: control logic configured to respectively present formal agreements to one or more sellers upon their accepting their respective seller bank SBRD offers.
 18. A transaction processing system comprising: control logic configured to collect receivable information relating to a plurality of transactions between a plurality of buyers and a plurality of sellers, wherein the receivable information includes information relating to receivable due to be received by a plurality of seller banks on behalf of the plurality of sellers; and control logic configured to allow the plurality of seller banks to utilize the collected receivable information to offer seller bank receivable discounting (SBRD) to the plurality of sellers respectively.
 19. The transaction processing system of claim 18 further comprising: control logic configured to display one or more SBRD-qualified transactions to a seller, wherein the one or more SBRD-qualified transactions are selected from the plurality of transactions and the one or more SBRD-qualified transactions are transactions having receivables belonging to the seller; control logic configured to allow the seller to request SBRD for one or more transactions selected from the one or more SBRD-qualified transactions; control logic configured to display the one or more selected transactions respectively to one or more seller banks, wherein the one or more seller banks are in charge of receiving payments on the one or more selected transactions respectively on behalf of the seller; and control logic configured to allow the one or more seller banks to review and approve respectively the one or more selected transactions.
 20. The transaction processing system of claim 19 further comprising: control logic configured to allow the one or more seller banks to respectively identify the one or more SBRD-qualified transactions before the one or more SBRD-qualified transactions are displayed to the seller.
 21. The transaction processing system of claim 19 further comprising: control logic configured to inform the one or more seller banks of transactions that potentially qualify for SBRD when those transactions are assigned a bank-assured status, wherein the one or more seller banks are in charge of respectively handling receivables pertaining to those transactions.
 22. The transaction processing system of claim 19 wherein the one or more SBRD-qualified transactions include transactions having a bank-assured status and/or transactions that have been approved respectively by the one or more seller banks for SBRD.
 23. The transaction processing system of claim 19 further comprising: control logic configured to maintain general terms and conditions provided respectively by the one or more seller banks, wherein the general terms and conditions can be modified by the one or more seller banks; and control logic configured to allow the one or more seller banks to respectively specify terms and conditions tailored to one or more approved transactions for SBRD.
 24. The transaction processing system of claim 23 further comprising: control logic configured to respectively present to the seller for acceptance the one or more approved transactions, the general terms and conditions, and the specified terms and conditions corresponding to the one or more approved transactions.
 25. The transaction processing system of claim 19 further comprising: control logic configured to inform the seller of one or more seller bank SBRD offers made respectively by the one or more seller banks; and control logic configured to allow the seller to accept or reject the one or more seller bank SBRD offers.
 26. The transaction processing system of claim 25 further comprising: control logic configured to present a formal agreement to the seller upon the seller accepting one of the one or more seller bank SBRD offers. 